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Tandem free Operation in a Communication Network 

The present invention relates to the call set-up in a communication network. The 
5 invention especially relates to a method for set up a tandem free operation in a 
communication network for speech communication between a first communication 
terminal and a second communication terminal, whereby at least one of the 
terminals uses at least one codec type to encode the speech signals into an encoded 
data representation, with a first transcoder and a second transcoder wherein 
10 messages are send from the first ttanscoder to the second transcoder and vice versa 
to determine if both communication terminals have at least one codec type in 
common and if this is the case to establish a data connection between the first 

communication terminal and the second communication terminal without having the 

» 

need to insert transcoding functions into the signal path between the first and the 
1 5 second communication terminal comprising the steps of exchanging messages 

between the trariscoders that contain information on the encoder type currently used 
by tfie communication terminals, exchanging a second message between the 
trariscoders as a response to the first message if both reported codec types match. 

20 DESCRIPTION OF THE PRIOR ART 

In digital systems for mobile communication speech signals arc encoded by a 
speech encoder in order to reduce the data rate for saving bandwidth. In a normal 
call originating in a mobile station (MS) and terminating in a mobile station (MS), a 
so-called mobile to mobile call (MS-MS), the speech signal usually is encoded and 

25 decoded twice. In the originating mobile station the speech signal is encoded a first 
time before the encoded signal is sent over the air to a first base station A first 
transcoder decodes the encoded signal, which it receives from the first base station 
irito a so-called a-law/jx-law signal which i$ commonly used in fixed communication 
networks. The decoded signal is routed in the fixed network to a second base 

30 ' station. Before the second base station can transmit the signal the signal is encoded 
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again in a second transcoder. The encoded signal is emitted by. the second base 
station and is decoded in the terminating mobile station. The speech signal flow in 
the opposite direction is handled symmetrically. 

5 As in this configuration two encoder/decoder pairs are lined up (the first speech . 
encoder of the originating mobile station and the decoder of tine originating 
transcoder is regarded as a first pair and the speech encoder of the terminating 
transcoder and the speech decoder of the terminating mobile station is regarded as a 
second pair) this configuration is called a speech codec "tandem". The key 
10 inconvenience of a tandem configuration is the speech quality degradation 

introduced by the double transcoding. This degradation is usually more noticeable 
when the speech codecs are operating at low transmission rates. 

When the originating and terminating mobile stations are using the same type of 

15 speech codec, it is possible to transmit the speech frames received from the 
originating mobile station to the terminating mobile stadon without the need to 
activate the transcoding functions in the first and the second transfcoder, As then 
there is only one pair of encoder and decoder (that is the encoder in tbe originating 
.. mobile station tbe decoder in the. terminating mobile station) involved this 

20 configuration is called Tandem Free Operation (TFO). In modern networks, like 
UTMS, it is even possible to discard the whole Transcoder Hardware. This is then 
called a Transcoder Free Operation (TrFO). In TFO and TrFO mode the 
compressed speech signal is transmitted over the fixed network instead e.g. the 
usual a-law/n-law signal. Besides the improvement of the speech quality by 

25 avoiding double transcoding this also saves costs as the compressed signal needs 
less bandwidth in the fixed network and power is saved since transcoding is 
bypassed. All necessary methods for negotiating, establishing and maintaining a 
Tandem Free Operating connection (TFO connection) are standardized for Codec 
types without configuration parameters (e-g. in GSM 08.62 for GSMJFR, GSMJKR 

30 and GSM_EFR) or are going to be standardized for more complex codec types (e.g. 
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the adaptive multi-cod© rate (AMR)) by the 3 rd Generation Partnership Project 
(3GPP). In Technical Specification 3G TS 28.062 V.5.0.0; 3 rd . Generation 
Partnership project; Technical Specification Group Services & Systems Aspects; In- 
band Tandem Free Operation (TFO) of Speech Codecs; Stage 3- Service 
5 Description; Release 5 the content t of which is to be incorporated here by reference 
all aspects of Tandem Free Operation for 3GPP is explained in detail. 

Tandem Free Operation is activated and controlled in 3GPP by so-called Transcoder 
Units after the completion of the call set-up phase at both ends of a mobile-to- 

10 mobile call configuration. The TFO protocol is fiilly handled and terminated in the 
Transcoder Units. For this reason, the TTanscoder Units cannot be bypassed in 
Tandem Free Operation. This is the key difference with the feature called 
Transcoder Free Operation CTrFO) defined in 3GPP TS 23.153. In return, the 
Transcoder Units continuously monitor the normal Tandem Rree Operation and can 

15 terminate TFO as soon as necessary with limited impact on the speech quality. 
Before TFO is activated, the Transcoder Units exchange conventional 64 kbit/s 
PCM speech samples coded according to the ITU-T Recommendation G.71 1 [13] 
A-Law or ra-Law. The Transcoders can also exchange TFO messages by stealing 
the least significant bit in every J6th speech sample (see annex A of 3GPP TS 

20 28.062 V5.0.0 for the specification of the TFO message transmission rule and 

clauses 6 to 8 for the description of the TFO procedures and messages content). If 
compatible Speech Codec Types and Configurations are used at botb ends of the 
mobile-to-mobile call configuration, the Transcoders automatically activate TFO. If 
incompatible Speech Codec Types and/or Configurations are used at both ends, then 

25 a codec mismatch situation exists. TFO cannot be activated until the codec 

mismatch is resolved. Tbis capability is an optional feature involving other network 
elements of the Radio Access Network. 

Once TFO is activated, the Transcoder Units exchange TFO Frames carrying 
30 compressed speech and in-band signaling, which structure is derived from the GSM 



P16887-gsc 



24.04.02 



24.APR'2002 



13:4,0 +09112551666 



ERICSSON, PATENT&flJUREMBERG 



#1010 P. 004 



4 

TRAU Frames defined in the 3GPP TS 48.060 and 48.061 (see clause 5). The 
exchange of TFO messages Is still possible while TFO;is active. In this case, the 
stealing process will result in embedding a message in the synchronization pattern 
of the TFO Frame. 

5 

The protocol flow shown in Fig. 1 is an example where immediate TFO setup is 
possible, either because both sides use identical Codec Types and Configurations, oj 
because the Codec Types and/or Configurations are compatible in the "lower, 
contiguous subset". In the latter case potentially an optimisation phase might follow 
10 after TFO has been set up. 



Problem of Existing technqlooy 

15 If the transcoders find that the codec type cuwendy used by both mobile terminals 
are compatible they will enter into a tandem free operation mode. Although the 
mobile terminals often support a codec type with better properties (e.g. better speech 
quality, better data rate) than the currently used codec type very often they will not 

..start with the optitnal.codec type as in the described system only, one codec type can 

20 be signaled. If both radio subsystems would always report the best codec supported 
by the respective mobile terminal no agreement will be found and the 
communication will be started in tandem mode, although a tandem free operation 
mode would have been possible. Although procedures ensure that in course of the 
communication the communication connection can be switched to a common codec 

25 type and thus tandem free operation can be enabled later on the signal distortions in 
tandem operation mode are inconvenient. Therefore a common strategy is to report 
a codec type with lower properties but that is widely spread in order to establish a 
tandem free operation very early. As further on messages (TFO_REQ_L; Con_J*eq 
frames) are exchanged that report a Jist of supported codec types of each terminal in 

30 the course of the connection the codec type may be changed to a better codec type. 
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However the users of the mobile terminals will experience the change of the codec 
as (click) noise and wit! be irritated- ! 

The TFO standard version 5.0.0 was approved although other important decisions 
5 were still pending and although some shortcomings are known. 
The major shortcomings in version 5.0.0 are: 

No general TFOJVersion handling is included in 3GPP TFO ..Messages. 
This means that no differentiation* between older and newer TFO Versions is easily 
j o possible and leads to increased implementation effort. Some TFOJVersion elements 
are included for some codec types* but this is not general enough and comes too late 
in the TFOJProtocoL A TFOJVersion exchange exists in 3GPP2 standards (North 
America), but also this proposal sends the TFO Version too late (exactly when 
going into OPERATION) and it is not general enough (only a few bits reserved). 

15 

No sufficient extendibility for TFOJIEQ is defined. There is a proposal on the table 
to indicate AMR-WB support when the AMR-NB is the Active Codec Type. This 
was, however, not accepted, because it was found to be not general enough. The 

discussion revealed that an extendibility for the existing TFO_REQ messages would 

20 be beneficial. Ideas are welcome. Other may also work on this. Our proposal is in 
Attachment 2* 

No general solution exists to indicate support for Wideband speech (or any other 
alternative Codec Type) before.the TFO is already in OPERATION in narrowband 
25 speech (the active Codec Type). Falling into TFO causes a slight speech distortion* 
falling out does this again. So it is desireable to know beforehand that a better 
Codec Alternative exists. Our proposal is also in Attachment 2. 

No simple AMR-NB Configuration exchange. Recent discussions in 3GPP and 
30 Ericsson internal have the trend to simplify the AMR Configurations to a smaller 



Pl<5887-gsc 



24.04.02 



24.APR'2002 13:40 +09112551666 



ERICSSON, PATENTJgHyREMBERG 




#1010 P. 006 



number of combinations. However; no simple solution for negotiating this has been 
developed ! 



10 



15 



20 



25 



No simple AMR-WB Configuration exchange. The recent standardizations meetings 
discussed and approved such a substantial simplification for the AMR-WB Codec 
Family. However, also here no simple solution for negotiating tbis exists yet. 

Another problem is that different protocol versions of the tandem free operation 
mode have to be supported as the protocol versions so tar are not compatible. 

Implementations according to TFO version 4.x may use two specific ways to 
transmit alternative Codec Types and Configuration parameters: 

a) send TFOJREQ_L messages 

b) send so called Config frames. 

These config frames in release 4 can be embedded into NoJData frames (e.g. in 
speech pauses), into SAD frames and into some of the various AMR Speech frames. 
The disadvantages are many: 

J ) several different kinds of configuration frames need to be implemented 
. 2) these carry, different amounts of configuration parameters ([some do not carry all) 
and need separated handling 

3) some do not have enough space to include the AMOEV-'WB parameters 

4) none has space enough for the next or future Codec Types 

5) the configuration frames are all AMR specific and not codec-independent. 
Therefore for Release 5 a new, "generic configuration frame" was proposed 
approved. 



30 



Therefore this has become state of the art It simplifies implementations and allows 
future extensions. But: the TFO standard version 5.0.O does not specify how 
interaction between version 4 and version 5 shall be handled This is especially 
difficult as long as no TFO Version number is exchanged. 
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OBJECT OF THE INVENTION 

It is therefore an object of the invention to allow very early in the call establishment 
a tandem free operation with prefetably the best common codec type. It is a further 
object of the invention to cope with the problem of incompatible protocol versions. 



SUMMARY Q|F THE frl VpNTION 

10 

This problem is solved in that the iirst message contains further information on 
encoding capabilities of the respebtive communication terminal. 

Some TFOJtfessage Extension_Blocks are defined together with their coding and 
13 usage. See Attachment 2. The intention is to generalise and simplify the TFO 

Mechanism for complex Codec Types such as AMR and AMR-WB and maintain 
high efficiency and low delay in the TFO Protocol. 

For details see the attached word document It contains the original TFO JMessage 
definition (chapter 7 of the approved standard TS 28.062 Version 5.0.0) with 

20 additional revision marks for the new ideas. 

Exactly this document (in its final form) will be presented as official 3GPP "Change 
Request" and - if approved - will part of the standard, version 5.1 .x. 
For better understanding of the problems, please read the attached TFO-Standard 
TS 28.062 Version 5*0.0, especially section 6 and the Annex G.4.1 and Annex H. 

25 Overview: Annex G.4.1 shows the typical example of a TFO Setup, when both sides 
use actually a compatible Codec Type and Codec Configuration. A reprint of this 
flow chart from the TFO standard i$ given on the next page, with the part under 
discussion marked with blue background. This is state of the art. 
Argumentation: It is quite likely that in future releases of the GSM and UMTS 

30 networks speech calls will be setup with terminals arid networks that support 
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besides several Narrow-Band Cod^c Types (such as GSML.FR> GSMJEFR, or 
AMR-NB) also the AMR-WB, with substantially improved speech quality due to 
the Wjde-Band spectrum. But to get the advantage of this superior quality it is 
necessary that the whole path, both terminals and the network support this Codec 
Type. 



10 



In the early phase of deployment of this new Codec Type the likelihood that both 
end-terminals support this Codec Type is not very high. Thus typically the call will 
be started in NB quality, the TFO Protocol will then check whether WB is possible 
on both sides and finally the call will be transferred to WB quality. 



15 



With the currently standardised TFO Protocol-elements it is not possible to detect 
WB-capability before TFO is already set up. Therefore TFO must be terminated 
again, then the transfer to WB be done and finally TFO setup for the second time. 
This causes longer time until the wideband quality is available and it costs more 
distortions, because in general each TFO setup and release will cause a slight 
degradation (click or so). 



20 



-The new -TFO Protocol-elements will provide the necessary information on this 
alternative WB Codec Type already within the first TFOJREQ messages. Thus the 
TFO-Decision can be right the Burst time, saving time and distordon. 



25 



In one embodiment that further information relates to the version of the transcoder 
free protocol version that is supported by the transcoder. 

In another embodiment that further information comprises a list of additional codec 
types that are alternatively supported by the respective communication terminal. 



In another embodiment the further information comprises an indication that the 
30 message contains further informatioD. 
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The new (claimed) extensions add information elements to the early exchanged 
TFOJREQ and TFO^ACK Messages and by that enable much more sophisticated 
decisions in the block "IPO Decision '. Instead of going always into "Inuneaate 
5 TFO", these additional information elements allow the following variants: 

No TFO at all, because the TFO_Version numbers or other configuration 
parameters reveal that the current call scenario is not favorable for TFO. This is 
important under several aspects and may gain even more importance in future 
10 evolutions of the TFO Standard. 

One example for today: in TFO Protocol of Release 4.x.y so called "Configuration 
Parameters" are exchanged in a very specific and somehow scattered form within 
the Speech and No-Speecb frames- The implementation of this needs some effort. 

j 5 Still, the solution is not flexible enough for extensions and die concept had to be 
given up when the AMR-WB was introduced in Release 5.0-O- Here a new concept 
for Configuration exchange was developed by the patenteethat overcomes this 
shortcomings. It is much more general, future proof arid simpler to implement. But: 
. . , to be backward compatible it is xn general necessary t<i implement also the old 

20 mechanism. Now: with the early exchange of the TFO Version number it is possible 
that a Release 5 unit rejects the TFO attempt of a Release 4 unit and thus has a 
potential for eost saving. 

No immediate TFO, because the new information elements show that a better TFO 
25 Configuration is possible. Instead Immediate Optimisation is performed: The TFO 
Protocol requests a change in Codec Type and Codec Configuration from call 
control and establishes TFO after that changes, e.g. after the transfer to AMR-WB. 
This in turn guarantees faster TFO Setup for the optima) configuration and better 
overall speech quality due to fester setup and less TFO establish/fallback cases. 
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! * 

The latter case was already described in one specialised example in. standard-input 
document S4-0201 1 Ldoc, see attachments. This document shows also in Annex G.9 
the modified call flow. This is reprinted here on the next page. The new parts are 
marked with green background. It is already adapted a little bit by including the 
5 TFO Version (V er) in the messages, although in this example the Version has no 
influence. 

i • 

In another embodiment the version number is used in the receiving transcoder to 
look up a subset of an active codec set that is mandatory supported in eacb specific 
10 protocol version, wherby the transcoders compare that subset with the coder types 
supported by their mobile terminal and that the best codec type in common is 
chosen to enter into tandem free operation. 

After a successful TFO Negotiation, when the protocol is in state OPERATION tbe 
1 5 old or new Configuration frames can be used. Now both sides know tte TFO 
Versions and can decide how to handle the situation: ; ' 

a) V4.x <-> V4.x: use old Configuration fiaroes or! 



25 



the THDJ^OJL and TFO^ACK^ protocol. .. .. 

b) V4.x <-> V5.x: use old Configuration frames or 

the TFOJREQ_L and TFO_ACK^JL protocol. 

i 

c) V5.x <-> V5.x: use new Configuration frames or 

t 

This in turn leads to a faster TFO setup in AMR-WB speech quality and should 
result in improved user satisfaction. 

The TFO Messages are better prepared for further extensions. 
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The introduced TFO_Version negotiation allows deciding in ah early stage of the 
TFO JProtocoJ, whether TFO setup is desirable or not More implementation 
freedom for product design is the consequence. 



5 BftlffF PESCRffTlOyJ OF THE INVENT^ 

In the following the invention will be further described according to the figures and 
by means of examples 

Fig. 1 : is a functional diagram of a communication system 
10 Fig- 2 is a block diagram with the entities involved in a call between a 

GSM system and a 3GFP system 
Fig. 3 is a protocol flow diagram illustrating the flow of messages . 
Fig. 4 is a protocol flow diagram illustrating the flow of messages and 

the additional information included in the different messages. 

15 

Embodiment of the Invention 

FIG.l shows a functional diagram of a system for mobile communication for 
exchanging speech signals between a first subscriber and a second subscriber. The 

20 communication system is shown in simplified form and is illustrative of a call 
routing mechanism between subscriber units within tbelcommunication system. 
Although the both subscriber units depicted in Fig. 1 arc mobile terminals a 
subscriber unit also may be a fixed.site terminal. However as fixed subscribers 
usually do not support a codec type tandem free operation is not possible in this 

25 case- 
In die example depicted in Fig. 1 two mobile terminals are exchanging speech 
signals. For the sake of brevity, the communication system is illustrated and 
described with only limited amounts of infrastructure and subscriber equipment, 

30 although it will be readily appreciated that the system will comprise many 
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subscribers, base transceiver stations, TRAUs etc.lfor example" E.g. in some 
implementations additional switches may be used to freely assign TRAUs to 
different communication lines etc. ' 



10 



15 



20 



7 TFO Messages 

■ 

The TFO Messages, introduced in fclause 6, follow the generic 
defined in annex A of 3GPP TS 281062 V5.0.0. 1 

's 

The following definitions are provided for the Sender side 



ISJMessage principle 



TFO capable device, using 



25 



2EO_jySQ_Q: Identifies the source of the message as s 
a defined Codec_Type. 

i 

TFO_REQ contains the following parameters (): ! 

• the System_Identification of the sender; i 

• the specific LocaLSignature of the sender, 
the Local_Used - Codec - ,Type at sender side; 

• possibly additional attributes for the Local_Used. _Codec_Type. 

• possibly additionally the Tip_Version 

• possibly additionally alternative CodecJTypes (s lortform of Codec_List) 

• possibly additionally a future TFO^Extension 

i 

TFO ACKQ Is the response to a TFOJREQ Message! 
TFO_ACK contains the corresponding parameters as Tf OJRBQ, except for the 
LocaI_Sig D amre replaced by the Reflected.Signature, copied from the received 
TFOJREQ Message. 1 \ 
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TFO JREO-X 0: Is sent in case of Codec Mismatch ox 
information. 

TFOJREQJL contains the following parameters Q: 
• the SysteraJCdentificatiou of the sender, 



for sporadic updates of 



] 



• the specific LocaLSignature of the sender; 

• the LocalLUsedjCodecJType at sender side; 

• the LocaLCodecJList of alternative CodeeJTypejs; 



• possibly additional attributes,** the used and thejalteraative CodecJTypes. 

i 

2 
I 

TFO ACKJLO: Is the response to a TFOJREQJL Message. 
TFO_ACKLL contains the corresponding parameters a! > TFO_REQ_L, except for 
tbe LocaLSignature replaced by tbfe Reflected_Signatuj;e 7 copied from the received 
TFOJREQJL Message. 

TFO TRANS O: Commands possible IPEs to let the TjFO Frames pass 
transparently within the LSB (8 kbit/s) or the two LSBs (16 kbit/s) or rtie four LSBs 
(32kbit/s). TFO JTRANS contains the following parameter Q: . 

• the Local„ChanneLType (8 kbit/s or 16 kbit/s or 32 kbit/s). 

TFO_NORMAk= Commands possible IPEs to revert to normal operation. 
TFOJSTORMAL has no parameters. 

i 

> 

TFO PUP; Informs tbe distant partner that TFO Frames are received, while still 
25 transmitting PCM samples. 
TFO_DUP has no parameters. 
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> 

TFO.SYL: Informs the distant partner (if soil possible)* that T-FO Frames are no 
longer received. 
TFO_SYL has no parameters. 



10 



15 



20 
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TFO ^ ILL: Message without specific meaning, used jo pre-synchronise IPEs or to 
bridge over gaps in TFO protocols, TFOJFILL has no parameters. 

7.1 EXTENDIBILITY j 
A mechanism for future extensions is defined in a way that existing 
implementations in the field shall b,e able to ignore future, for them unknown 
CodecJTypes and their potential attributes. The existin \ implementations shall be 
able to decode the remainder of the messages (which isJicnown.ro them) 
uncompromised. This mechanism allows to extent: 

• the number of Local JJsed_Codecjrypes from 1 J (short form) up to 255 
(long form) for one SystemJdentification; \ ■ 

! 

• the CodecJUst; : 

• the Codec_Attributes (if needed). 

In case of the TFOJREQ or TFO_ACK messages the ai tributes of the 
t^caCtJsedjC6aec_Type shall tie/sent In the codec sp^ific w'ayi without a 
preceding Codec_Attribute_Head ExtensionJBlock. Existing equipment, that do not 
know a future Codec_Type and therefore do not know jjf and how many attribute 
Extension_BIocks do follow, shallskip these Extensioi^JBlocks, until they find a 
TFO Message Header again. Similarly, if future Extensjon_Blocks to a known 
CodecJType are detected, existing; equipment shall skip| these Extension JBlocks, 
until they find a TFO Message Header again. 



the simple Codec JJst shall 



In case of the TFO_REQ_L or TFO_ACK w L Messages 
be sent immediately after the SIGJLUC and possible C0dec_jx Extension JBlocks. 
Then the attributes of all alternative CodecJTypes sbaUjfoilow; Each set of codec 
attributes shall be preceded by roe.Codec_AttributeJHead Extension__B1ock (with 
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CodecJType Identifier and Length Indicator) followed by the dodec specific 
attributes. 

7.2 Regular and Embedded TFO Messages 

A TFO Message is called "regular", if it is sent inserts^ into the PCM sample 
stream. A TFO Message is called "embedded", if it is esmbedded into a TFO Frame. 
The bit stealing scheme, as defined in Annex A, is identical for regular and 
embedded TFO Messages. The EMBED bit of the TFOjFrames (see clause 5) 
indicates if the TFO Frame contains an embedded TFO jMessage. Due to the specific 
construction of the TFO Messages, tbey replace some o|f the synchronisation bits of 
the TFO Frames. Consequently, the TFO Frame syuchr >oisation pattern will be 
affected by the presence of an embedded TFO Message^ without compromising the 
synchronisation performances. Data and other control bfts of the TFO Frames are 
not affected by embedded TFO Messages. 

7.3 Cyclic redundancy Check 
The Extension JBlocks, defined in the following claused shall be protected by three 
CRC parity bits. These shall be generated as defined in die 3GPP TS 48.060 for the 
Enhanced Full Rate. For simplicity the present document is reprinted here: - 
"These parity bits are added to the bits of tbe subset, according to a degenerate 
(shortened) cyclic code using the generator polynomial: 

g(D) « D 3 + D + I 

The encoding of the cyclic code is performed in a syste: natic form which means 
that, in GF(2), the polynomial: • 

d(m)D n + d(ra+l)D n -' + .+ d(m + n-3)D 3 + j>(0)D 2 + p(l)D + p(2) 

where p(0), p(l), p(2) ate tbe parity bits, when divided by g(D), yields a remainder 
equal to: j 
1 +D + D 2 ! 
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For every CRC the transmission order is p(0) firstjfollawed by'p(l) and p(2) 
successively/' 

In case of Extension JBlocks, p(0)..p(2) are mapped to t its 16..1 8. 
7.4 TFOJREQ Messages 
Symbolic Notation: 

« 

TFO_REQ (SyaJH, LSig, LocaLUsed_Codecjrypfe[, Used_Codec_Attributes] ) 
TFO_REQ_L (Sys_Id, LSig, Local_Used_Codec_Type, CodecJList t, 
Altemative_Codec_Attributes] ) j 

i 

The TFOJREQ Messages conform to the ISJREQ Message fotraat, defined in the 

Annex A, with IS_SysteroJ[dentification, followed by ihe SIG JLUC 

Extension_£lock, optionally the Codec_x Extension3iock, the CodecJList 

ExtensionJ8luck(s) and the Codec_Attribute ExtensioijjMocks. 

The shortest TFOJREQ takes 140 ms for transnussionjsee Figure 7.4-1. 

The shortest TFO_REQJL takes 180 ms (Figure 7.4-2)1 j 



15 



20 



20bit$ — ► *l0bits*'«—20bits — 20bils • 
+ — dOore *«-20ms*«« — 40m$ — 




Figure 7.4-1: Construction of the shortest possible TFOJREQ Message 




< — 20bits 



-*«J0bHs** — 2Qbiu 



20Wts 
— 40nr&- 



-20bits 



Figure 7.4-2: Construction of the shortest possible TFO^REQ^L Message 



«— 20bte.« 
+ — 40ms- 



'-•lObits** — 20bits - 
• ««-20ins* * — dQms- 



**--aObit$ 




-20bits 4—++-^ 20bit$ 
■~40m$ 



I 



— 40ms- 



-20bits 



— 20bits 
— 40ms 



Figure 7.4-3: Example of a TFO_REQ Mesiage with a Code© 
with an index higher than 15 and with three Attribute 
. Extension_Btocks (300 ms length) 
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-*I Obits**— 20bils« 
■♦•20ms* < — 40ms- 



• *-"7<20bii$ - 



20blts- 
— 40ms- 



ZObits * 
40ms- 



-«*— 20biis- 



*■« — 40ros- 



Figuro 7.4-4: Examp|e of a TFO _REGLL Message with 
Codec_List and one alternative Codeo with two Attribute 
Extension_Blocks (300 ms length) 



A TFOJSEQ CTFO^ACK) may bave an additional TFd.Versipn ExtcnsionJBlock 
that contains the TFO_Ver$ion.Subversion and a Selector. This Selector may 
indicate future extensions to TFO_REQ (TFO_ACK), \)toich may require further 
additional ExtensionJBlocks following the TFO^Versiin, see figure 7.4-5. 

i 




*i0bks^ «*— 20bits 



— 20bits ■ 
— 40m$ - 



20bits 
r40ms 



* — 40ms 



Figure 7.4-5: Construction ot a TFO_REQ Message with Selector, 
TFO Versi on-Subversion j 
and one additional Extension JBIock 



7.4.1 Definition of THE SIG LUC EXTENSION BLOCK 

The SIG_LUC ExtensionJEilock consists of 20 bite, as defined jn Table 7.4.1-1. It 
shall always follow immediately after the SYSJDD ExtensioiuBlock. It 
differentiates a TFOJREQ from a TFO_REQJL message and a TFO^ACK from a 
TFO^ACKJL message. 

The Codec_x ExtensionJMock shall also be used in T^p_REQ or TFQJUEQJL 
messages if the Local JLTsedjCodecJType has a CoID Higher than 14. 
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Table 7.4.1-1: SIGJ.UC Extensionl.Block j 



Bit 

Bit 1 
Bit 2 




Comment ' j fc ~ T ~ " 

normeJ IS-Messaae Svno Bit. constant 

indicates, whether the CodecJJst is; included hi the- TFO Message or not 
0: S: TFO_REQ or TFO_ACK: Codec_Ust is* not included (short) ' 
1: U TFO REQ Lor TFO ACK LrlCodec ,List is included (lona> 


Bil 3..10 
Bit 11 


Big 

«o u 


An 8-bit random number to facilitate jtha dsteetlon of circuit loop back conditions an 
identify the message source \ 


Bit 12.. 15: 
BIM8..18: 


Codec_Type 
CoID_s 
(short form) 

CRC 


normal IS-Messaae Sync Bit r constant ! 

Identifies the LocaLUsed^CodecJType, whidh is currently used by the sender " 

00OO...1110: reserved for 15 Codec_Typeu 

1111: Codee^x Extension_B lock follows Immediately 

1 ! ' „ 


Bit 19..20: 


ex = -o.o" 


3 CRC bits orotectino Bits 2 to 1 0 and 1 2 to 1 5 
The normal^ bits for ISJvlessage Extension.' 
No other extension block follows j 
An other extension block follows 



7.4.2 Definition op the Codec x exte nsion Block 
The Codec_x ExtensiooJ3lock, if present, always follows the SIGJLUC 
Exten 5 ion_Block. It consists of 20 bits.as defined in Table 7.4.2-1. It shall follow 
always immediately after the SIGJLUC ExtensionJSlock, if the CodecJType field 
Is set to "1H I". 

Table 7.4.2-1: Codee_x Extension_Block 



Bit 
Bit 1 


Description 

ItQU 

Codec^Sel 


Comment! | 

normal IS-Messaae Sync Bit. constant 

Differentiates tho Codec^x Extension Block 

0s U: Used_Codec_Type is defined 1 . In Codec Type^x field 

1: Reserved ."" 


BU3..10 

Bit 11 

Bit 12.. 15: 


Codec JTypejx 
ColD 

(lonq form) 
"O" 

°1010 n 


Identifies the LocaLUsed^Codeojrype, wh | 0 h is currently used by the sender 
0000.0000^.1111.1111 reserved for 255 Codec Types 
0000.1111 Is undefined and shall not be used. 


Bit 16..18: 
Bit19..20: 


CRC 

ex : 


Reserved for future use. set to "1 01 0" to minimise audible effects 

3 CRC bits' prgtectinq Bits 2 to 1 0 arid 1 2 to 1,5 — | 

The.normal 2 bits for IS Message Extension: 

00: No other extension block follows] 

1 1 : An other extension block follows; 



JO 



7.4.3 DgyiNmoN ofthb Codec, Lis t JExtension Bi.onc ' 
The Codec_List ExtensionJBlock is used in a TFO_REfJ_L, TFO_ACK_L 
messages to list the supported CodecJTypes. It consistsjof 20 bits, as defined in 
] 5 Table 7.4.3-1. The Codec_List mu,st at least contain the- Local JUsed^CodecJType. 
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If a system supports more than 12 Codec JTypes, then other CqdecJList 
ExtensionJSlocks (Table 7.43-2) may follow. 

Table 7.4.9-1: CodecJJst Extension Block 



Bit 


Description 


Comment 


BH1 




Norma) iS-Messaqe Syrio Bit, constant. 


BU2..10 


Codec JJstJI 


First part of CodecJJst. For e&ch CodecJType one bit fs reserved. 
If the bit is set to "0' then the Specific Codeo^Type Is not supported; 
if the bit Is set to "l" then the jJoecific CodecJTvoe could t>e used. 


Bit 11 




Normal iS-Messaqe Svnc Bit, {constant 


Bit 12.. 14: 


CodecJUstj2 


Second part of the Ccdec_UsJ: All three bits are reserved for future 
Codec Tvoes (up to Codec «voe 12) : 


Bit 15 


CodecJJst_x 


If set to "l- a further Codec Ust Extension_Btock follows; 
otherwise set to n 0" 1 


Bit16..18: 


CRC 


3 CRC bits protectino Bits 2 to 10 and 12 to 15 


Bit 19-.20: 


EX ■ 


The normal 2 bite for ISJUee^age Extension: 
00: No other extension block follows < 
1 1 ; An other extension btock follows I 


Table 7.4.3-2: Further CodecJJst Extension Block(s) 


Bit 


Description 


| Comment 


Bit1 




norma! IS-Message Sync Bit .'constant 


Bit2-.10 


CodeoJUstjlx 


First part of CodeoJJst. For 4ach CodecJType one bit is reserved. 
If the bit Is set to *0" then the specific Codec JTyre is not supported: 
if the bit is set to "i* then the Specific CodecJType could be used. 
Bit 2: CodecJType 13 (+ XMSj; X&1..2..3) 
Bit 4: CodecJType 14 (+ xMS; >c=1 ..2.3) 
and so on ]_ 


Bit 11 


ItQH 


normal IS-Message Svnc BitJconstant 


Bit 12.. 14: 


C0de0_Ust_2x 


Second part of the CodecJJdt; All three bits are reserved for future 
Codec Tvoes (up to Codec Tvoe 24 £+x*12: xsl ..2,.3) 


Bit 15 


CodecJJsOcx 


It set to M u a further Codec_Utet ExtensioruBiock follows; 
otherwise set to "o* I 


Bit 16..1B: 


CRC 


3 CRC bits protecting Bits 2 to 10 and r 12 to 15 


Bit 19.50: 


EX" 


The normal 2 bits for ISJVIespage Extension: 
00: No other extension biockjoliows 
11: An other extension block follows 



7.4.4 Definition of the Codec Attribute Heap 



sion Block 



Tbe Codec w A.ttribute_Hea<J Extension_Block (Table Tj.4.4-1) shall precede tbe 
Codec Attribute Extension JSiocks of a CodecJType, |f this CodecJType needs 
additional attributes. This Codec_Attribute__Head idenjtjfxes the CodecJType and the 
number of additional Extension_Blocks to follow. 
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Table 7,4.4-1: CodeciAttribute_JHead Extension jBtock 



Bit 


Description 


Comment [ 


Bit 1 




normal IS-Message Sync Bit. cohstani 


Bit Z 


PAOel 


Differentiates this Extension_BtcjcK * 

0: Parameters Included in PAR field: Simble CodeoJJsUSxtension 
1: Length indicator (LI) fnoludedJ-ParamrfefsfoKow In subsequent 
ExtenslonJBIooks j \ 


B[t3..10 


ColD 


This field identifies the CodecJType for Which the subsequent attributes, are 
valid. The same coding as in thd CodecJc Extension Block fe used (long form) 


Bit 11 


Bqh 


normal IS-Messaae Sync Bit, eobstant j 


Bit 12.. 15: 


LI / PAR 


If Par_Sel=a1: U: Length Indicator. 

Q000; reserved; [ j 

0001: one other Extenslon_Bloox follows! etc. 

If Par Sel=s0: PAR: Codec specific definition of these four bits 


BR16..18; 


CRC 


3 CRC bits protectinp Bits Z to 110 and 1 2 to 1 S 


Bit 19..20: 


EX 


The normal 2 bits for isjviessajie extension: 
00: No other extension block follow© j 
1 1 : An other extension block folfows 



NOTE: This ExteusionJJlock shall be used for the codecs introduced in the 

I « 

future that need attributes. It shall precede die Attribute 
Extension JEUocks. This allows earlier versions to Skip the blocks they 
do not understand. It shall not be used for tijie GSNjLFR, GSMLHR and 
GSMJ5FR Codec_T>jies. 



7.4,5 PEFINTTION OPTHETFO VERSION E XTENSION kuOCK : 



The TFO^Version ExtensionJSlock (Table 7.4.5-1 ) co itains t|ie "TFOJVersion" (4 
bit), the 'TFCLSubversion 1 ' (4 bit) and a "Selector 0 (Slit). Thd TFOJVersion 
Extension Block (and the additional ExtensiotuBlocks 

any, see belpw) shall always be tbp last of Extension JEf locks of a TFO_REQ or 
TFOJREQJL (orTFO_ACK or TFCLACKLL) message. This, is necessary to 
provide compatibility with older versions, wbich mustfce ableito skip these 
Extension_Blocks without being effected negatively. 



The TFOJVersion and TTO^Subyersion are specified 
implementation of Release 5 or onwards shall send tbik 
omitted then aTFO^Version lower than 5 shall be 



n Annex H. ATFO 
IPOjVersion.Ifit is 
assumed by the receiving side. 



I 
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-Unved distinction 




iative Codecs 

m then already bg*r 
LACKme^ co $ ec types in an early 




> protocol, i.e„ 



is established. Forxsach alternative 



CodecJTyjpe that is offered during TFO negotiation, oiie Codejc^AttributeJHead 
ExtensionJBJock shall be included. JTthe specified Cctf ecJType requires additional 
attributes ttiSifcthe required nijinber of Codec_Attribut«j ExtensionJSlocks follow 



dec_AttributeJHeadExtOTsioti3tock. Th< 



CodecJTypes is terminated when the EX bits indicate jio further ExtenstonJJlocks 
(00) and fee next TFO Message Header is following. 



list of alternative 
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Table 7.4.5-1: TFOJVersion Extension_B1odk 




REMBERG 
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Bit 1 
Bit 2..6 



IB1I7..10 



Description 



Selector 



Ver 



jr 

Sver 



Bit 11 



CftC 

BU19..20: EX 



Comment 



normal IS-ft/tessaae Sync Bit, constaht 



L 



Indicates If and which further extensionJMocKs are followino. 
Coding for bits 2.34.5.6: J y 

00000: nothing Is foHgwIng after thtefTPO^Verslon 
00O01: One (or more) alternative CcMeoTypefe) Is (are) following, 10101: 
reserved (used by the l$_Header) ' 
atl other codes: reserved for future Jse. 



This field contains the TFpjVerslonlnumber as specified in Annex H 



L normal IS-Messaoe Svnc Bit, oonstdnt 



This field c ontains the TFQ_Subverslon number as specified in Annex H 



3 CRC bits protecting Bits 2 to 10 arid 12 to 15 



The normal 2 bits for iSjMessfege Extension: 
00: No other extension block folli 
1 : An other extension block Toll' 



Used_Codec_Attributes] ) 
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7.5 TFO_ACK Messages 
Symbolic Notation: 

TFO_ACK(SysJM, RSig, tocal JUsedjTodecJType [, 
TFO_ACKJL (Sysjtd, RSig, IxralJUsed^odecjrype, Codicjtist [, 
AlterDative_Codec_Attributes] ). 
The TFO_ACK Messages conform to the IS_ACK Message, c efined ia the Annex 
A, with IS_Systen\Jdenrification, followed by the SIGJLUC 
and optionally the Codec_x ExtensiooJBlock, the CodicJList 
and the C6dec_Attribute ExtensionJBlocks. 
TFO_ACK and TFOJREQ Messages differ only in thaACK / 
block and the construction of the Signature: LocaI_Sig tature i i case of TFOJREQ, 
ReflectedJSignature in case of TFO^ACK. All extensi to blocjts defined for the 
TFOJREQ are valid as weJJ for TFCLACK. 
The shortest TFO_ACK takes 140 ms for transmission 
The shortest TFO_ACKJL takes 1 80 ms. 



Extension JBlock, 
ExtensionJBIock(s) 

REQ Command 



20 



7.6 TFO JTRANS MESSAGES 
Symbolic Notation: TFO JTRANS (ChannelJType) 
Two TFO JTRANS Messages are defined in conformity 
in Annex A of 3GFP TS 28.062 V5-0.0. 



to the ISJTRANS Messages 
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is used and is identical to < 



23 



For 8 kbit/s submultiplexing the "TfOJTRANS (8k)" is used juid is identical to 
"IS_TRANS_l_u". 

For 16 kbit/s submultiplexing the "TTFOJTRANS (Ink)' 
TSJTRANSJZ_u tt . 

For 32 kbit/s submultiplexing the "TFO.TRANS (32k)" is us<fd and is identical to 
"IS_TRANS_4_u". 

TFO_TRANS() takes 100 ms for transmission. 

In most cases the respective TFO JTRANS Message shill be seht twice: once as a 
regular TFO Message, exactly before any series of TFO Framep , and once 
embedded into the first TFO Frames, see clause 10. 

7.7 TFOJNORMAL ME5SAGE 
Symbolic Notation: TFO_JNORMAL. 
The TFOJSrORMAL Message is identical to the IS_NORMAIJ Message defined in 
the Annex A of 3GPP TS 28.062 V5.0-0 j 
It shall be sent at least once whenever an established Tandem Free Operation needs 
to be terminated in a controlled way. 
TFO _JNORMAL takes 100 ms for transmission.- 



7.8 TFOJFELL MESSAGE 
Symbolic Notation: TFO JHLL. 
The TFOJFILL Message is identical to the ISJFILL Message, 
A of 3GFP TS 28.062 V5.0.0. 

TFO_JFILL may be used to pre-synchronise IPEs. Sincd 



i 



defined in the Annex 



ISJFIIX* is one of the 

25 shortest IS Messages, this is the fastest way to synchror ise IPE 5, without IPEs 

swallowing other protocol elements. By default three T rOJFIl L messages shall be 
sent at the beginning; this number may be, however, configuration dependent. 
One TFO_FILL takes 60 ms for transmission. 
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7.9 TFOJDUP Message 
Symbolic Notation: TFOJDUP 
The TFCLDUP Message is identical to the ISJDUP Me ssage, defined in Annex A. 
TFOJXJP informs the distant TFO Partner, that TFO Irames 
unexpected, e.g. during Establishment. This enables a fast re-e itablishment of TFO 
after a heal handover. 
TFOJDUP takes 60 ms for transmission. 
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! 

7.10 ' TFO_SYL Message 

Symbolic Notation: TFO__SYL | 

The TFOJSYL Message is identical to the IS_SYL Message, .„.,.„. 

TFO_SYL informs we distant TFO Partner, that tandem free c peration has existed, 
but suddenly no TFO Frames were received anymore. This en ibl.es a fast re- 
establishment of TFO after a distant handover. 
TFO_SYL takes 60 ms for transmission. 

7.11 Specification of the TFO messages 
7.11.1 Copgr. JxsES - 

The CodecJTypes are defined according to 3GPP TS 26.103, table 6.3-1. 
The short form (CoID_s) exists fcV all CodecJTypes w ith indices below 15 and 
consists of the last four bits (LSBs) of the long form (< loJD). 



7.11.2 Codec. List 

The Codec_List Is defined according to 3GPP TS 26.lk>3. The mapping into the 
CodecJList Extension block shall be as follows; bit 1 of octet 
Bit 2 of the Codec_List Extension block, and so on until bit 4 
placed into Bit 14. 
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If more than 12 Codec Types are contained in the CodecJList, 1 hen Bit 15 of the | 



first Codec JList Extension block shall be set to T and 



an further Codec JList 



Extension block shall be added for the next 12 Codec Types. 
7.11.3 Codec Type Attributes : 

The CodecJTypes GSM Full Rate, GSM Half Rate and GSM Enhanced Full Rate 
do not need additional attributes. They are fully defined by the 
Systemjdentification (see Annex A.5) and the Codec type. 



7. 1 1 .3.1 AMR Codec Typb ! attributes 
The Adaptive Multi-Rate CodecJTypes (FR^AMR, HR_AMR, 
UMTSJAMR^) and the Adaptive. Multi-Rate Wideband 
WB and UMTS_AMR-"WB) need several attributes 
TFO _ACK as well as in the TFOJEU&QJL and 
ConJReq and Con^Ack frames see Annex C 



There are two major kinds of attributes: the ACS (Active Code c Set) and potentially 
the SCS (Supported Codec SeflThe ACS is related to tl le Loca w U5ed_Codec_Type 
and is part of the Used_Codec_At4ibutes. One and exa ctly on< > ACS shall be sent ii t 
all cases where the Local_Used_Codec_Type is FR_A AR, HI ^AMR, 
UMTS_AMR, or UMTS_AMR_2; FR_AMR-WB or I MTS^AMR-WB within one 
ACSJExtension_Block. This ACsLExtensionJBlock c urries some more parameters 
as defined in the next clause, the most important one-is 
indicating whether or not the full set or a sub-set of the AMR ijAMR-WB) is 
supported. In TFOJEUEQ and TFO._A.CK Messages the} ACS shall follow 
immediately after the SlGJLUC_Extension_£lock. In 
TFO_ACKJL Messages an AttributeJH[ead_ExtensionU8iock 
Local jCodecJList, indicating the Codec JType it specifies, followed by the 
corresponding ACSJExtension_plock. 



. Codec. 



wit lin the 



TFO_ACKJL Messages 
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The SC5 shall be sent in TFOJREQ' or TFO_ACK only if the 
ACS_ExtensidnJBlock indicates that the sending side di>es not 
of AMR codec modes, but a subset (FulLSub flag). In t lis case 
SCSJExtension_Block shall follow immediately after tt e ACS 
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support the full set 
the 

.ExtensionJBIock. 



NOTE 1 : Hence, the TFO JProtocol can decide iinJnediate|ly after the reception 
of TFOJREQ or TFO_ACK whether TFO i s possib le or not, and can 
report the distant TFO parameters to the Co ltrol Ei tity in the Network. 

One and only one ACS JBxtensionJSIock is included in TFO J tEQJL and 
TFO_ACK_L, if the Local_Used_Codec_Type is FR _J MR, H R^AMR, 
UMTS_AMR or UMTS_AMR_2, FR_AMR-WB or Ul 4TS_A MR-WB. In addition 
one SCS_Exten$ion_Block is needed for each AMR Codecjrype flagged in the 
LocaJ_Codec_List. In that case an AttributeJHead jExt« nsion_ Jlock shall follow 
after the Local_CodecJList, indicating the CodecJType it spec fies, followed by the 
corresponding SCSJExtension JBlock. If multiple AMRjCodeoJTypes are flagged, 
then multiple AttributeJHeads and'SCSJExtensionJBlc cks ma y be needed. If the 
full set of AMR Codec Modes is supported, then neithe : the At tributeJHead nor the 
SCSJExtensionJBlock shall be sent for the alternative < :odec_' Type(s). 
The following figures give the examples for the fulll S et AMR TFO Messages 



-20bits ■ 



■••10WtS'"*-^Obits- 
• *-20ms* + ' 4 0ms- 
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Ffgure 7.1 1 .3.1--| : Construction 6f the shortest 
possible TFOJRE0. Message for any AMR Cod ec Type 



TFO_ACK follows the same construction. Bom have a 



"* — 40ms- 



20bits 
■* 40ms- 



-•lOblts— -— 20Wts • 



Sfiaii 



40rw 




Figure 7.11.3.1-2; Construction 
possible TFO_REQlL Message listing ar 
In the CodecJJst 



of the shortest 
AMR CodecJType 
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engtbif 180ras. 



HI 



! ZObits- 
+ — 4k)rm- 




ZObits 
— aoros- 
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TFO_ACKJL follows the same construction. Bothihave a length of 260ms 



#1010 P. 027 



ODe Aqribute_Head is 

AMR-WB, because 



NOTE 2: In.TFOJREQJ- (TFO_ACKJL) at least 

needed, if the Local_Used_Codec_Type is AMR oi 
otherwise a TFO partner that does not know the 
Local_Osed_Codec_Type cannot know hov many 
- if any. Since these longer messages are us ;d only 
identified or in other situations, where protc col spe id is not important, 
this additional 40ms message length is not iraportaiiL 



In the worst case in GSM, when both AMR Codec_Typ£s and 
are flagged in the Codec_List, but none supports the full set, th 
Extension JBlocks need to follow after the CodecJList 

Example: FR^AMR = Local_Used_Codec_Type: Attijibute Head(FR^AMR) - 
ACS(FR_AMR) - SCS(FR_AMR) - Attribute_Head(H R^AMR) - SCS(HR_AMR) 
- AttributeJHead(FR_AMR-WB) - SCS(FRJVMR-WB) 



attributes are needed 
when mismatch is 



he FR_AMR-WB 

;o seven 



7.11.3.1.1 AMR Active Codec Set Attributes 



P16887-gsc 



idded in the 



One AJMDR_ACS (AMR-WB_ACS) ExtensionJBlock s htall be 
TFOJREQ and TFO_ACK messages after the SIGJLU 2 Extei sion_E1ock if an 
AMR (AMR-WB) Codec_Type is used as the LocaL.uied_Codec_.Type. 
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Table 7.11A1/M: AMR_ACS Extensijon3Iofck 



Bit 



Bit 1 
Bit 2..9 



Bit 10 



Bit 11 



Bit 12 



Bit 13 



Bit 14 & 15 



Sft16..18 



Bit19..20: 



Description 



Active Codec Set 
(NBJVCS) 



Fu!i_8ub 
(NBJF/S) 



spare 



Optimisation Mod© 
(NBjOM) 



NB_Ver 



CRC 



EX 



Comment 



J 



Normal IS-Message Sync Bit constant 



#1010 P. 028 



CddscJMo^e 
hen the 
nay be 



Active Codeo Set: For each 
reserved. If the bit is set to "0* 
the ACS. otherwise it Is In and 
algorithm. 

Bit 2: AMc\JV|ode 12,2 kbit/s (dndefinec 
Bit 3: AMRJUode 10,2 kbitfe (i ndefinec 
Bit 4: AMR Jtf ode 7,95 kbIVs 
Bit 5: AMRJVIode 7.40 kbit/s 
Bit S: AMRJVlQde 6,70 kbIVs 
8it 7: AMRJVIode 5.90 kbitfe 
Bit 3: AMR_ModB 5,15 kbitfe 
Bit 9: AMR_Mode 4.7B kbitte 



of the AMR one bit is 
specific CodecJWode is nfct In 
Used by tne adaptation 



for HR_amr) 
for HR_AMR) 



Full Set supported, NBjSCSj Is not fallowing 
Subset only supported, NBjSCS is fallowing immediately 



Normal IS-Message Sync Bit T 



set to "1 



ACS Optimisation Mode 

0 No ACS Change sup. 

1 ACS change supported 



Version Number of the AMR-MB TFO i 
Bit 15 Is equivalent to the ATvAl In Conli 




3 CRC bits protecting Bits 2 tol10 and 112 to 15 



I 



ieme 

juration Frames, see An 



The normal 2 bits for ISJWess&ge Extension; 
00: No other extension block f Allows 
11: An other extension block fallows (I 
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Table 7,11.3.1.1-2: AMR-WB_ACS Extension .Block 



Bit 



Bit1 



Bit 2-10 



Description 



Active Cod ec 



Bit 11 



Bit 12 



Bit 13 



Bit 14 



BH 15 



BMe..18 



BU 19-20: 



Comment 



SeT 



Normal iS-Message Sync Bit, constant 



-0" 



Full_Sub 

cwb1p/s> 



Optimisation 
(WB_OM) 



Mode 



spare 



cparo 



CRC 



± 



JViode 
i the 



Active Codec Set For each CoddcJ 
reserved, if the bit is set to "O" IN n the specific 
the ACS, otherwise it is in and m$y be us^d 
algorithm. 

Bit 2i AMR-WBJMode 23.85 kbit/fe 
Bit 3: AMR-WBLMode 23.05 kbit/fe 
Bit 4: AMR-WBJMode 19.85 kbit/s 
Bit 5: AMR-WBJMode 13,25 Kbit 
Bit 6: AMR-WBJVJode 15.85 
Bit 7: AMR-WBJWode 14.25 kblt& 
Bit 8: AMR-WBJMode 12.65 Kbitfe 
Bit 9: AMR-WBJMode 8.85 kbitfe 
Bit 10: AMR»WB_Mode 5.60 



kbitfe 



Normal iS-Messago Sync Bit, oofrstant 



0: Full Set supported, WB^SCS 
1 : Subset only supported, WB_S 



ACS Optimisation Mode 
0: No ACS Change supported 
t ACS Change supported 



\ 3 not folI6wtng- 
3S is follbwlnq immediately 



set to -r 



set to "l" 



3 CRC bits protecting Bits 2 to 1 0 and 1 2 to 15 



Extens 



on: 



The normal 2 bits tor ISJWessag e 1 
00: No other extension block foil* ws 
1 1: An other extension block foilAws (i.e. SCS) 



7,11.3-1.2 AMR SUPPORTED CODEC_SBT ATTRIBUTES 



10 



The AMRJSCS (AMR-WJ3_SCS) Extension JBlock, cdntaius 
AMR (AMR-WB) Supported Codec Set. It shell be otr itted, it 
supported. Table 7,1 1.3.1.2-1 gives the description of t lie SCS 
For the Local_Used_CodecJType the SCS Extension^ JlocH shall 
immediately after the corresponding ACS Extension JE lock. 
FulUSub flag shall be set within the ACS Extension JB lock. Ffrr 
CodecJTypes, as flagged in the LocaLCodecJList, thej SCS 
immediately after the corresponding Attribute JHead 
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of the AMR-WB one bit is 
CodeoJMode is not 
by the adaptation 



i he information on the 
the full set is 
ExtensionJBlock. 

follow 
that case the 
alternative 
follow 



shall 



EttensioiJBlock. 
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NOTE: The VERsion numbers in ACS and SCjS ExtensionJjBloglK} shall be 



identical for one CodecJType, bat may be different 



CodecJTypes (e.g. FR_AMR and HR^AMR or FR JVMR-WB). 



Table 7.11.3.1.2-1: AMR.SCS Extenslon_BI<fck 



Bit 



BH2...9 



*Q» 



lion 



Bit 10 



Bit 11 



Bit12...13 



Bit14...15 



BU16V18 



Bit 19 20 



Supported Codec Set 
<NB_SCS) 



NB_MACS MSB 



NB JMACS LSBs 



NBJVer 



CRC 



EX 



comment 



± 



#1010 P.030 



for different 



Normal IS-Messaoe Sync Sit constant. 



Supported Codec Sot: For 
reserved, if the bit fs set toj 
supported; If the bit is set tj 
supported and may be coi 
common ACS. 
Bit 2i AMRJViode 12,2 kbi 
Bit 3: AMR_Mode 10,2 kbi 
Bit 4: AMFLMode 7,95 kbtys 
Bit 5: AMRJWotje 7,4 kblt/f 
Bit 6: AMRJWode 6.7 kbit/I 
Bit7:AMr\JMode5,9kbl 
Bit8:AMRJWode 5,15 W 
Bit9:AMR,Mode4.75 kbi 



See comment for Bit 12...13 




CotfeoJV/lode of the AMR one bit is 
fie specific Codecjtfode is not 
the specific Codecjviodfe Is 
the optimisation of the 

(undefined in 5CS(H)) 
(undefined inSCS(H)) 



normal iS»Message Sync Bit, constant 



The maximally supported 
leg. Coding for bits 10.12- 
0.0.1" 1 Mode 
D 0.1.0*2Modss 
0.1.1" 3 Modes 
a 1.0.O" 4 Modes 
•1 .0.1" 5 Modes 
"1,1.0" 6 Modes 
1.1.1" 7 Modes 
"0.0.0" 8 Modes 



i tumber df Codec JVtodes in this radio 
3: 



Version Number of the 
Bit 1 5 is equivalent to the 
Annex C 



3 CRC bits protecting Bits 



The normal 2 bits for IS Message Extension: 
00: No other extension bit ok follows 
1 1 : An other extension block fotkwfe 
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2 to 10 



AMR TFO Scheme for that CodecJT*} pe 
MVN In Configuration Frames, see 
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Table 7.11.3.1.2-2: AMR-WB.SCS Exterislon.B 



#10X0 P. 031 



Bit 1 



Bit2...10 



Description 



Supported Codec 
(WB_SCS) 



Bit 11 



Bit12...14 



Bit 15 



Blt16..18 



Bit 19 20 



Comment 



or 



Normal IS-Message Syno Sit r constant 



Supported Codec Set: For 
bit is reserved. If the bit is 
is not supported; if the bit \4 set to "1 
Codecjvtode Is supported and may 
optimisation of the common WB_AC|S 
Btt SU AMR-WB_Mode 23.85 kbitfe 
Bit 3: AMR-WB_Mode 23.05 kbit/s 
4: AMR-WBJVIode 19.85 kbit/s 
Bit 5; AMR-WB_Mode 18.25 kbit/s 
Bit 6: AMR.WB.Mode 15.8b kbit/s 
Bit 7: AMR-WBjMode 14.25 kbit/s 
Bit 8: AMR-WBJMode 12.® kblt/s 
Bit 9: AMR-WBJWode 8.85 kblt/s 
Bit 10; AMR-WB Mode 6.90 kbit/s 



0? 



WBJWACS 



WB_Ver 



CRC 



EX 



ock 



fach CodeoJWode of the AMR-Wi 
»t to "0" 4hen the specfflo Codec J 
~ i ' then the specific 
be considered for the 



normai IS-Message Svnc Bit, constant 



The maximally supported 
leg. Coding: 

0.0.1" 1 Mode 

0.1.0° 2 Modes 

0.1-1 d 3Modes 

'1 .0.0" 4 Modes 
"1.0.1" 5 Modes 
"1.1.0° 6 Modes 

1.1 .1*7 Modes 

0.0.0" 8 Modes 



umber oi 



AnnexC 



Version Number of the AM H-WB TKO Scheme. 
BU 15 Is equivalent to the ATVN In (Configuration Frames, see 



CodeoJVtodes in this radio 



3 CRC bits P 



Bits 



id 12 to 15 



The normal 2 bits for IS_Wfessage Extension: 
00: No other extension bio k follow ; 
11: An other extension block follows 



one 

lode 



7. 1 1 .3. 1 .3 AMR SPECIFIC CODEC ATTRIBUT E HH/Id EXlfosiON JO£CK 



The AMR specific Codec_AttributeJrlead Extension J Hock C 
shall precede the Codec Attribute Extension JBIocks of any AJjflR 



If PARjSel is set to "(P then one of 16 possible AMR 
the PAR field and no additional Codec Attribute Extension JBI 
10 . Coding for PAR (bits 12.13,14.15): 

0000: AMR_ACS with 10.2 / 6.70 / 5.90 / 4.75, NBJFS set to 
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able 7.11.3.1.3-1) 
Codec JType. 



Configurations is indicated iii 
ocks do follow. 



"0" and OM set to 
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0001: AMR.ACS with 10.2/6.70/5.90/4.75, NBJFS set to 
„ r 

0010: AMR_ACS with 7.4 / 6.70 / 5.90 / 4.75, NBJFS (set to 
00 11 : AMR^ACS with 7.4 / 6.70 / 5.90 / 4.75, NB JrS |set to 
s other: reserved for future use. 



If PARJSel is set to. "1" then the AMR.ACS and potenAaHy A **R_SCS is/are 
following. 

Table 7.11,3.1-3-1: AMR specific Codeo_Attribute. Head E ctensionJBIock 



Bit 



Bit1 



Comment 



Bits 



Bit3.,10 



Bit 11 



PAR_.Se! 



ColDs 
HRJMWR 

UMTS_AMR 

UMTS_AMR2 

OHR^AMR 



normal IS-Message Svnc Bit, constgnT 



Differentiates this Extenslon^Block 
Q: Parameters included in PAR field Simple 
1: Length Indicator (LI) Included; Parameters 
ExtensIon_Blocka 



This field Identifies the AMR Codec jType for 
valid. The same coding ae In the ~ 



Colfec^x Extensionjlock 2s used (long form) 



normal IS-Message Sync Bit constant 
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0" and OM set to 



andOMsetto ,, 0 , \ 
andOMsetto'T. 



SodecJLIsL&tension 
follow in subsequent 



which the subsequent attributes are 



15 



Bit 19..20: 



CBC 



W Par_Sefc»l: U: Length Indloaton 
0000: reserved; 

0001: one other Extension_eiockfo 
If Par_Se|gsQ; PAW; Codec specific 



lows, etc . 
deflnKtor 



3 ORC bits protecting Bjta a to 10 aijid 18 to -ts 



of these four bite 



The normal 2 bits for ISJvlessage Extension 
00: No other extension block follom 
' 1 ; An other extension block follows 



AMR-WB SPECIFIC! Conrr ATrpTttin-p 



The AMR-WB specific 
1) shall precede the Codec Attribute 
Codec_Type. 



Codec_AttributeJHead Extensi anJSlofck 



HEADfexTENSIQ^ BTryoq 



ExtejisiojoJ31ocks of any 



(Table 7.1 1.3.1.4- 
\MR-WB 



If PARjSel is set to "0" then one of 16 possible AMR 
indicated in the PAR field and no additional Codec 
0 folJow.Coding for PAR (bits 12.13.14.15): 

0000: AMR-WB^ACS with 1 2.65 / 8.85 / 6.60. 

0001: AMR-WB^ACS with 15.85 / 12.65 / 8.85 / 6.60. 



wB Configurations is 
Attribute Extension JBlocks do 
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0010: AMR-WB^iCS with 23.85 / 12.65 / 8.85 / 6.60. 
other: reserved for future use. 

If PAK_Sel is set to "l" then the AMR-WB JVCS and potentially AMVWB_SCS 
is/are following. 



Table 7.11.3.1.4-1: AMR-WB specific Codee_Attribu e_Heae 



Bit 


Description 


Comment _ 






BU1 
BH2 


"0° 

PAflLSel 


normal IS-Messaqe Svnc Bit, consW 
dill erentlatas this Extenslon_BlocK 
0: Parameters Included in PAR ftelc 
1: Length Indicator (U) included: Pi 
Extension Blocks 


: Simple 
ramsten 


CodecL.UsL.pxtension 
follow In subsequent 


BHt 3..10 


ColDs 

FR^AMR-WB 

UMTS_AMR-WB 

OHR_AMR-WB 

OFR_AMR-WB 


This field identifies the AMR-WB cd 
attributes are valid. The same codir 
used (iong form) 


decjryp 
9 as in U 


a for which the subsequent 
e Codec_x ExtenstorLBIock ts 


Bit 11 

Bit 12.. 15: 


U/PAB 


normal IS-Messaae Svnc Bit. const 
If Par_Sel=»1: U: Length indicator. 
0000: reserved; 

0001 : one other Extension_Block U 
If Par 5el=0: PAR: Codec specific 
3 CRC bits protectina Bits 2 to 10 6 


ant 

Hows, et 
definHfo 
nd 1210 


i of these four bits 
15 


jBtt 19~20: 


CRC 

r 


Thenormal 2 bits for ISJVtessage l 
00: No other extension block follow 
1 1 : An other extension block follow 1 


jrtensior 

5 





10 



Extens!on_Block 
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Claims 
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■ V 



1 . Method for set up a tandem free operation in a conu minicat [on network for 
speech communication between a first communication terotnal (local MS) and a 
second communication tenminat (distant MS), wher *by at Ifeast one of the 
terminals uses at least one codec type to encode the speechjsiguals into an 
encoded data representation, with a first transcoder CTRAU ) and a second 
transcoder (TC) wherein messages are send from th s first t anscoder to the 
second transcoder and vice versa to determine if bo ft cotm nunication terminals 
(local MS, distant MS) have at least one codec type in common and if this is the 
case to establish a data connection between the first comm mication tenninal 
and the second communication terminal without hst wig th< \ need to insert 
transcoding functions into the signal path between t he first and the second 
communication terminal comprising the steps of: 

- exchanging messages (TFOJREQ) between the ransco( lers that contain 
information (LUC;DUC) on the encoder type cu rrently 
communication terminals, 

- exchanging a second message (TnFCLACK) betv een the 
- response to the first message (TFOJREQ) if bot i reported codec types match 

characterized in that the first message contains further inform? tion (Ver; AMR^WB 
) on encoding capabilities of tbe respective communic tfion terminal. 



2. ^Method for set-up a transcoder free operation acco riing tc 



further information relates to the version (Ver) of t tie transcoder free protocol 
version that is supported by the transcoder CTRAU ; TC). 



3. Method for set-up a transcoder free 
that further information comprises a list of additional 
alternatively supported by the respective communication terxxfcoal 



operation according to 
dodec tj 



jsed by the 



transcoders as a 



claim 1, wherein that 



:l.aim I or 2 f wherein 
pes that are 
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4. Method for set-up a transcoder free operation according to cljaim 1, 2 or 3, 
wherein the farther information comprises an indicatioiq that th£ message contains 
further information. 



JO 



5. Method for set-up a transcoder free operation according to cl 
wherein the version number is used in the receiving trax scoder 
of an active codec set that is mandatory supported in 
version, wherby the transcoders compare that subs© : 
supported by their mobile terminal and that the 
chosen to enter into tandem free operation. 



best codec 



aim 2 

to look up a subset 
each s pecific protocol 
with tl te coder types 
type in common is 
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Terminal A 



RAN A 



Transcoder 



Digital 



Radio Leg 



Fig.l 



BTS 

! ! s 



t 
t 
f 
i 




wise 



XTj 



64 kbit/s Speech Samples carryl ig 

- TFO Frames on the LSB containing 

- Compressed speech samples 

- Control bits 
-TFO Messages 

- Original PCM speech samples \*n the M$B 



Fig. 2 
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| BSC ((oc) | | PT5 QOC) | 



Rate Control wnrtm 
tun low* set 

byBTS 



Rate Control fnto 
tfo setup subset 
by local THAU 




TFO. 



REQ (LUC. LACS. LOM) 



TFO^BEQ (OUC. DACS. I OM) 



tfo Decision: immediate tfo possible, 
on a subset Of the full set 



TFO^ACK 



TFO^ACK 



u 



TFO_Suon 



Rate Control waNn 
subsotbyBTS 



BTS stops 
Time Alignment 



TFO.Soon 



TPO_ACK 



Tin* p. 



TFOL.TRANS 



TFO Frames 



nans 



TFO_TRANS 



CMRwcRCs. 
-TFO_On_ 



Rate Control witntn 
common set by 9T9 



Delay and distant tfo 

parameters known 
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tpq Report 
(dls Par) 



Con..Req(fJts) 



Coo_Ack Coo) 



CcruROQ (toe) 



CoruAck (dls) 



TFO Frames 



Exenange of tfo frames 
Con Jteq (oT$) 



CoTV-Ack (loe) 



OoruRoq (loo) 



Con_Ack (dls) 
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S?NC (dl3) I j MSC (dl3r~] 



Rate 
tu 



CoMrol witnin 
t distant set 
by RNC 



eq (=<RCij 



Ratd Control within 
surest by RNC 



.AIIgivRedj 



Tlme_A Ign (not Suj ) 



^CJ^ckO 



PC M Req(*cR( !s) 



RC^AckQ 



FGJUKlO 



f C_Aek() 



ReteControJIntO 
TFO Setup subset 
by dstant TC 



a potential Tbtte 
Aflnnment ettempt 
Is icjectod 



Control wiAtn 
comrhon set by RNC 



TFO Report (opt mal Configuration) ^ 
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The remaining protocol flow is as in normal Imnicd 



ateTFO 



Setup 
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ABSTRACT j 

A Method for set vip a tandem free operation in a communication network for 
speech communication between a first communication, termiua 
second communication terminal (distant MS) is discrito d, whei eby at least one of 
the terminals uses at least one codec type to encode the speech signals into an 
encoded data representation, with a first trariscoder (TR AU) an d a second transcoder 
(TC) wherein messages are send from the first transcdd to th< > second transcoder 
and vice versa to determine if both communication tepa tfnals (1 
have at least one codec type in common and if this is th 3 
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1 o connection between the first communication terminal a id the s econd 



art transcoding functions into 



terminal. In order to 



communication terminal without having the need to ins 
the signal path between the fiist and the second comma nicatioi 
provide a very early possibility to establish a tandem jfr se oper ition wj>h the best 
codec type common to both mobile terminals it is prqp< >sed tfc t the first message 
contains further information (Ver; AMRJWB ) on encoding capabilities of the , 
respective communication terminal. 



Fig. 4 



ocalMS, distant MS) 
case to establish a data 
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